REMARKS 



The above amendment and these remarks are in response 
to the Office action of 13 July 2004 by Examiner 
Narayanswamy Subramanian. 

Applicants file this amendment and reply under 3 7 CFR 
1.111 in response to the action of the Examiner reopening 
prosecution to cite newly discovered art in view of the 
appeal filed on 5 Feb 2004. 

Claims 12-19 are in the case, none having been allowed. 

Drawings 

The Examiner objects to the informal drawings filed in 
this application. 

Formal drawings, which had been sent previously to the 
Office on or about 29 October 2001, have apparently been 
misplaced. For the convenience of the Examiner, a second 
set of formal drawings is included with this 
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Amendment /Response . 



35 U.S.C. 103 

Claims 12, 14, and 15 have been rejected under 35 
U.S.C. 103(a) Anderson et al . (US Patent 6,05,380, sic, 
6,058,380, hereinafter, Anderson) in view of Rail et al . (US 
Patent 5,680,611, hereinafter. Rail). 

Claims 13 and 16-19 have been rejected under 35 U.S.C. 
103 (a) over Anderson in view of Rail and further in view of 
Smith et al . (US Patent 5,111,395, hereinafter. Smith). 

With respect to claims 12, 14, and 15, applicants 
traverse the Examiner's characterizations of the teachings 
of Anderson and Rail. 

With respect to Anderson, the Examiner refers to Column 
4, which states: 

"Each of the paper invoices and Electronic Invoices 
(collectively "Invoices") is stored in a distinct 
record in an invoice table in intermediary database 66. 
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Each record has an identifier that indicates the type 
of Invoice... Before an Invoice is stored in 
intermediary database 66, however, certain checks are 
performed to maintain the integrity or consistency of 
the data stored in intermediary database 66. For 
example, if a received Invoice does not include an 
invoice number, a unique invoice number is generated 
for the Invoice based on an algorithm, e.g., the 
account number plus designated date. All EDI Invoices 
are guaranteed to have an invoice number as part of the 
EDI transaction. Moreover, checks are made to ensure 
that the Invoice is associated with an existing 
account, that the Invoice has been received in the 
manner that the customer has specified for that 
account, that the Invoice is not a duplicate and that 
the vendor has sent all expected Invoices. If an 
exception is detected, action is taken in accordance 
with Table 1 and an exception report is generated in 
accordance with Table 2." (Anderson, Col. 4, lines 21- 
41.) 

Based on these references, the Examiner asserts that 
Anderson teaches : 
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1. preprocessing original electronic invoices before 
introduction into an accounts payable data base; 

2. identifying invoices having same vendor invoice 
designation, same purchase order number; and same 
item number is inherent in 810/811 invoices (see, 
Office Action, page 3) . 

As to these assertions, applicants demur without prejudice. 

The Examiner states that Anderson does not teach the 
steps of calculating a net sum of items for a record (which 
applicants teach as the manner for identifying duplicate 
invoices) , nor communicating a transaction from an 
intermediary to the vendor. (Office Action, page 3) . For 
calculation of net sums to identify duplicate invoices the 
Examiner refers to Rail and for communicating a transaction 
(rejection) relies on official notice. 

With respect to Rail, the Examiner states: 

"Rail teaches the steps of calculating a net sum 
of items for a record, and identifying as a 
duplicate record an original record for which said 
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net sum is greater than zero (See Rail abstract, 
Column 3 lines 55-57, Column 5 lines 38-49 and 
claims 1 and 2) . 

Applicants traverse this characterization of Rail and 
the official notice. First, with respect to Rail, 
applicants assert that Rail does not teach applicants 
claims, which recite "calculating a net sum amount of items on 
invoices identified as having said same vendor invoice 
designation, said same purchase order number, and said same item 
number" in order to identify duplicate invoices. This is 
what Rail teaches: 

"A method for detecting duplicate records 
generates a check- sum (222) for each record and 
compares the generated checksum (222) to checksums 
stored in check files (30) . In a particular 
application, a system (10) for processing call detail 
records utilizes a duplicate check module (28) that 
detects duplicate records using checksum processing." 
(Rail, Abstract) . 

"Duplicate check module 28... generates a checksum 
for each processed CDR. The checksum is one or a 
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combination of values computed using the contents of at 
least a portion of each processed CDR. The generated 
checksum is then compared to stored checksums of 
previously processed CDRs located in check files... 
30." (Rail, Col. 2, lines 51-57). 

"Using the selected key fields of the record, the 
method generates a checksum at step 104. In general, a 
checksum is one or a combination of values computed 
using the contents of at least a portion of the record. 
This may be accomplished using a cyclic redundance 
checksum (CRC) routine that is common in computer 
communications applications. For example, a 
transmitting device may generate a CRC. on an outgoing 
transmission block and append the CRC to the block for 
transmission. The receiver detects transmission errors 
by comparing the appended CRC with a locally calculated 
CRC. If the appended CRC and locally calculated CRC do 
not match, an error is detected and the block is 
retransmitted." (Rail, Col 3, lines 54-66). 

"Any system that checks historical records for 
duplication of a uniquely identifiable event or 
transaction would find value in the performance gains 
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and file storage savings offered by the use of 
checksums for duplicate record detection... (Rail, 
Col . 5, lines 42-46) . 

It is apparent that Rail does not teach applicants 
process for identifying duplicate invoices. A checksum as 
described by Rail is a cyclic redundancy check (CRC) value 
and is not a "zero sum" as that is used in applicants' 
claims. Rail is determining the checksum for all records. 
A CRC value is not related to a sum of invoice amounts as 
required by applicants claims, which state: 

''calculatincf a net sum of items on invoices identified as 
having said same vendor invoice designation, said same 
purchase order number, and said same item number" 

Rail, in order to identify duplicates, determines if two 
records resolve to the same CRC value, not to whether the 
sum of invoice amounts on selected invoices exceeds zero. 
Applicants traverse the assertion of the Examiner to the 
contrary. 

Because Rail does not teach applicants calculation of 
invoice sum amounts, there is no basis for combining Rail 
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with Anderson as is done by the Examiner (see Office Action, 
page 4, second paragraph) . 

The Examiner notes that neither Anderson nor Rail teach 
automatically rejecting back to a vendor those invoices 
deemed to be duplicates. However, the Examiner takes 
official notice that this step is old and well known in the 
art and that it facilitates better and faster communication 
between the parties concerned. "This step" is "the step of 
communicating a transaction from an intermediary to the 
vendor" . But "this step" is not what applicants claim. 
What applicants claim is: 

"...identifying as a duplicate invoice an original 
electronic invoice for which said net sum is greater than 
zero; 

"automatically communicating a duplicate invoice rejection 
transaction back to said vendor for said original electronic 
invoice identified as a duplicate invoice without posting 
said original electronic invoice to said accounts payable 
data base" . 

Consequently, applicants traverse. 
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The Examiner is using applicants' own disclosure 
against their claims and drawing on official notice for 
which no specific reference has been supplied. Because it is 
based in part on personal knowledge ("official notice"), 
applicants request under 37 C.F.R. Section 1.107(b) an 
affidavit of the Examiner that provides citation in support 
of the above assertion at page 4, lines 10-11. This will 
allow applicants to analyze the specific teachings upon 
which the Examiner relies, and enable them to prepare and 
submit explanatory affidavits in rebuttal. 

Rail in combination with the teachings of Anderson and 
the assertion made by official notice do not teach to one of 
ordinary skill in the art the rejection of invoices to 
vendors based upon zero sum logic. Rail clearly teaches a 
method to review call records to prevent a record from 
appearing twice on a bill being sent to a customer. Its 
teachings clearly indicate that after matching the call 
records, if a duplicate is found, that the duplicate goes to 
an audit file, and is not rejected back to a vendor. 

Rail does not teach to one of ordinary skill in the art 
the use of net sum logic for evaluating invoices. Rail 
deals with the creation of bills to be sent for payment, not 
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for invoices received for payment. Rail teaches a method 
that creates a "checksum" (specific characteristics of an 
invoice to be sent) and compares the checksum to checksums 
of previously created invoices to ensure a duplicate bill is 
not mailed. There is no teaching of how to prevent invoices 
to be paid from entering the database using a net zero logic 
which involves summing the invoice amounts of selected 
invoices. A 'checksum' (of which the CRC is an example) is 
not a net-sum-greater-than-zero calculation based on invoice 
amounts as is set forth in applicants' claim. 

With respect to claims 13 and 16-19, the Examiner 
states that Anderson and Rail combined do not explicitly 
teach the step of sequentially sorting the records by 
various fields within a record in order to identify 
duplicate records. Applicants concur. 

However, the Examiner continues: 

"Smith teaches the step of sequentially sorting 
the records by various fields within a record in order 
to identify duplicate records." 

Applicants traverse . 
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Applicants are not merely sorting by various fields, 
but rather claim a specific order of sorts of specific 
fields in order to determine the net sum. Claim 13, for 
example, recites: 

"...first sorting said original electronic invoice 
against an accounts payable production table for same 
vendor and same vendor invoice number; 

"second sorting hits from said first sorting for same 
purchase order billed; 

"third sorting hits from said second sorting for same 
items billed on purchase order; 

"calculating a net sum of said same items..." 

This is what Smith teaches: 

"Such systems are designed to eliminate a 
duplicate record only when all data elements of the 
duplicate match exactly with the data elements of 
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another record. Key elements of the record are 
combined to form a matchcode, which is then attached to 
the original record and carried throughout the 
merge/purge process... In prior art merge/purge systems 
a duplicate record is identified only if all elements 
of each matchcode match exactly. ... As long as the set 
of criteria in one of the test sequences i satisfied, a 
duplicate is identified." (Smith, Col. 1, lines 39-45, 
49-51, Col. 13, lines 19-21). 

"1. An automated fund collection apparatus comprising: 

means for creating a file, said file comprising a 
plurality of records, each record including a name 
and address of an individual, 

means for selecting portions of each record, 

means for making a first comparison between a 
first predetermined portion of a first record and 
a first predetermined portion of at least one 
second record to determine if said first portions 
match, 



END919980071US1 



26 of 30 



S/N 09/244,304 



means for identifying at least one duplicate 
record in said file when at least said first 
portions match, 

means for making a second comparison between a 
second predetermined portion of said first record 
and a second predetermined portion of said at 
least one second record to determine if said 
second portions match, 

means for identifying at least one duplicate 
record in said file when at least said second 
portions match and said first portions do not 
match, 

means for eliminated identified duplicate records 
from said file and means for creating a second 
file of unique records, wherein no two records 
identify the same individual, 

means for creating a list of individuals from said 
second file of unique records, 

means for sending each individual on said list a 
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proposal for an electronic funds transfer 
agreement in which each individual agrees to make 
automatic and periodic transfers of funds from 
each individual to a fund collection entity and, 
means for printing a plurality of checks and means 
for sending one of said plurality of checks to 
each said individual." (Smith, claims 1). 

Applicants traverse the Examiner's characterization of 
Smith and the rationale for combing Smith with Anderson and 
Rail. Smith's matchcode is more like the CRC of Rail than 
applicants net sum. Smith does not teach any step of 
sequentially sorting records by various fields nor, more 
importantly, by the specific fields claimed by applicants. 

With respect to claims 16, 18 and 19, pages 5-8 of the 
Office Action contain the Examiner's reading of Anderson, 
Rail and Smith, official notice, and rationale for combining 
them in much the same way as discussed and traversed 
previously with respect to claims 12-15. As before, 
applicants' "net sum" is not the "checksum" (CRC) of Rail or 
the "matchcode" of Smith, and the specific sorts on specific 
fields claimed by applicants for determining the "net sum" 
is not suggested by any of the references. 
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In traversing the rejections of claims 16, 18 and 19, 
applicants argue that the Examiner has used hindsight 
reasoning based on applicants own disclosure to assemble 
concepts from the art references and official notice which 
are unlike concepts described and claimed by applicants. 



SUMMARY AND CONCLUSION 



Applicants urge that the above amendments be entered 
and the case passed to issue with claims 12-19. 

The Application is believed to be in condition for 
allowance and such action by the Examiner is urged. Should 
differences remain, however, which do not place one/more of 
the remaining claims in condition for allowance, the 
Examiner is requested to phone the undersigned at the number 
provided below for the purpose of providing constructive 
assistance and suggestions in accordance with M.P.E.P. 
Sections 707.02 (j) and 707.03 in order that allowable claims 
can be presented, thereby placing the Application in 
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condition for allowance without further proceedings being 
necessary. 



Date: 12 Oct 2004 

Shelley M Beckstrand, P.C. 
Attorney at Law 
61 Glenmont Road 
Woodlawn, VA 24381 

Phone: 276 238-1972 
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Sincerely, 



M. W. Beach, et al . 



By 




